A common information systems security measure that regulates the flow of information between two automated information systems (AIS) is a filter. Here, the term "AIS" refers to a computer, network of computers, internetwork of computers, or any subset thereof. A computer with a network address is known as a "host." A host may be a computer with either a fixed or temporary network address. A host with its own rules (known as a local rule base) for regulating the flow of information is called a "peer." Information on certain AIS flows in discrete quanta called "packets." Each packet on certain AIS has a header and a payload. The header comprises packet identification data. An example of packet identification data is a circuit identification number, which occurs in packets flowing in a circuit switched network. Another example of packet identification data is a 5-tuple consisting of a network source address and destination address, a source port and destination port, and a protocol identifier. The 5-tuple occurs in packets flowing in a connectionless packet switched network.
In accordance with the invention disclosed in co-pending application Ser. No. 08/785,501, entitled System and Method for Providing Peer Level Access Control on a Network, and filed on the same date as this application, a dynamic filter loads and stores a peer's local rule base when the peer is authenticated, and deletes (or "ejects") the rule base when the peer loses authentication. The filter is positioned between the peer and another AIS, such that packets that flow between the peer and the AIS pass through the filter. The filter receives a packet, and then searches for rules (usually in global and local rule bases) that that match the packet. A rule comprises a key and an action. The key identifies to which packets the rule applies, based upon the packet identification data of each packet. The action is generally either PASS or DROP, meaning that the packet is either forwarded to its intended destination, or else deleted. If a matching rule is found, the action prescribed by the matching rule is applied to the packet. One of the novel features of the dynamic filter is the ability to accommodate frequent changes in its local rule bases.
A filter in a typical setting is shown in FIG. 1. A corporate network 10 may wish to provide access for peers A 11, B 12 and C 13 to Internet 14, but may wish to limit the access that Internet hosts G 15, H 16 and I 17 have to the corporate network 10, which may contain trade secrets and proprietary information. The corporate network 10 places a filter 18 at the interface between the corporate network 10 and the Internet 14.
A filter operates on a packet by receiving a packet and searching for a rule whose key matches the identification data of the packet. If the received packet identification data matches the key of a rule, then the action of the rule is carried out on the packet.
In one embodiment, the filter stores rules that take the form of a 5-tuple, of similar structure to a packet's header, and an action, which is either PASS or DROP. The 5-tuple is advantageous to use because it allows the filter to distinguish packets not only based upon source and destination, but on the particular process with which the packet is involved. This is because several well-known processes (file transfer protocol, e-mail, etc.) use standard port numbers that are recognizable by the filter. Thus, in accordance with this embodiment, a filter may advantageously enforce a security policy which, for example, allows files to be transferred from host A to host B, but forbids the exchange of e-mail between the same two hosts.
An example of a rule base for corporate network 10 having peers A 11, B 12 and C 13, connected through filter 18 to the Internet 14 having hosts G 15, H 16 and I 17 is as follows:
SOURCE DESTINATION Address,Port Address, Port PROTOCOL ACTION A,21 G,32 4 PASS A,22 H,19 3 DROP G,11 A,64 4 DROP C,9 I,23 4 PASS
This rule base is defined by the network system administrator in accordance with the security requirements of the hosts on the network.
When a packet arrives at the filter, the filter determines if the packet 5-tuple matches any rule 5-tuple. Here the rule 5-tuple is the rule key. If there is a match, the filter carries out the matching rule action, either PASS or DROP.
A filter generally has a default rule for transactions that are not explicitly specified in the rule base. Thus, if there are no matching rules in the rule base, the packet is compared to the default rule. If there is a match, then the default action is carried out, which is usually to DROP the packet. If there is no match to the default rule, then an error message is generated. In one embodiment the default rule may be structured so that all packets match the default rule so that no error message is ever generated.
By selectively passing and dropping packets between peers and hosts, the filter regulates the flow of information to and from AIS which are said to be "behind" or "protected by" the filter. In FIG. 1, the corporate network 10 is behind filter 18.
A traditional filter is only able to load and store rules through the intervention of a system administrator, a slow and cumbersome process. Indeed, the system administrator generally must hand-code rules in a format specific to the filter platform. These rules are based upon a security policy promulgated by the protected AIS. Hence, a traditional rule base is inflexible and cannot easily accommodate the changing security needs of the protected AIS.
This inflexibility often necessitates rule bases that are too broad for a given application. Without the possibility of easy updates, it is simpler to mandate global rules that apply to all AIS behind a filter rather than to load rules that apply to specific hosts. In such a case, all AIS behind the filter must conform to the most restrictive security requirements of any such AIS, resulting in overly restrictive filtering.
Even when rules are formulated to apply to individual hosts behind a firewall, such a level of access control may be insufficient. An example of this situation occurs for Internet Service Providers (ISP). An ISP has subscribers that are generally stand-alone personal computers having modems. The ISP has one or more hosts, each host connected to the Internet and having a pool of Internet Protocol (IP) addresses. When a subscriber dials-in to an ISP host (called a Point-of-Presence, or POP), the POP assigns the subscriber a temporary IP address from its pool of IP addresses. This temporary address generally corresponds to the calling subscriber only for a single session of connectivity. A future session is likely to result in another IP address being assigned to the subscriber.
This is problematic because rules are based in part upon network source and destination addresses. Thus, known filters cannot effectively control access to subscribers because their IP addresses change on a session by session basis.
The dynamic filter disclosed in co-pending application Ser. No. 08/785,501, entitled System and Method for Providing Peer Level Access Control on a Network, and filed on the same date as this application, remedies this deficiency by providing a system and method by which a subscriber's rules may be dynamically loaded into the filter when the host is authenticated, and ejected when the host is no longer authenticated. While the rules are stored in the dynamic filter, the rules correspond to the subscriber's temporary IP address, and thus can be effectuated.
The dynamic filter has yet broader application because it can also easily and dynamically change the rules in the filter for any peer, including a peer with a fixed IP address, not just for an ISP subscriber. Hence, the dynamic filter provides better access control that may be tailored to a specific peer's security needs and easily accommodates changes in those security needs. Thus, the novel utility of a dynamic filter derives from its ability to accommodate and implement frequently changing local rule bases.
An exemplary embodiment of a dynamic filter operates by receiving a packet and searching a pre-global rule base for matching rules. If no matching global pre-rules are found, a local rule base is searched using hash tables for matching local rules. If no matching local rules are found, then a global post-rule base is searched for matching rules. If no matching global post-rules are found, then a default rule is applied if it matches the packet. If the default rule does not match the packet, then an error condition is generated. When any matching rule is found, and the rule's action is DROP, the packet is dropped and no further rules are searched.
Searching rule bases for matching rules consumes both time and processor power. Hash tables for the local rule base in the dynamic filter improve the efficiency of the search process substantially. However, the dynamic filter must perform a hash function and carry out a search of the rule bases for each packet the filter receives. This involves substantial and unnecessary redundancy, because all of the packets in a particular message generally have the same 5-tuple.
For example, suppose data file A is broken into 320 packets for transmission from host A through host A port 20 to host B through host B port 21 using protocol X. The header for each of the 320 packets will comprise the 5-tuple: EQU A,20,B,21,X
When the first of such packets arrive at the dynamic filter, the filter searches the rule bases for matching rules and applies them. When the next packet arrives, it again carries out the same search, finds the matching rules, and applies them.
A known solution to this problem is to keep a short list (known as a "cache") of rules for recently processed packets that have been derived from the filter rule base. Each rule in the cache stores a cache entry comprising a key (such as a 5-tuple) and action derived from a full-scale search of the filter rule bases for the first packet received in a given message. When a packet is received, the cache is searched first for a matching entry (i.e., for an entry whose key matches the received packet identification data.) This is more efficient than searching the rule bases for subsequent packets in the same message that have the same key. If a cache entry matches, the action of the entry is carried out on the packet without having to search the rule bases. In other words, subsequent packets essentially benefit from the search done for the first packet in the message. This saves processor time and increases the throughput of the filter.
It should be noted that this known caching technique is designed for traditional, static filters with rule bases that are fixed and do not change. This technique cannot be used effectively with a cache for a dynamic filter whose local rule bases change frequently. This is because this known technique provides no way of tracking and ensuring the currency of a cache entry. In other words, a rule from which an entry is derived in a dynamic filter may change frequently. Known caching techniques cannot ensure that outdated entries are not applied to packets. Traditional filter caches are completely emptied whenever there is a rare change in the underlying rule base, and is subsequently reconstructed in accordance with the new rule bases as packets are received and filtered. This is inefficient because the cache is flushed even if the vast majority of cache rules unaffected by the rule change and are still valid, and is only acceptable because such rule changes occur so infrequently in traditional static filters.
Emptying a cache for a dynamic filter every time the rule bases changes would be unacceptably inefficient because the local rule bases change so frequently. A known cache implemented on a dynamic filter would have to be rebuilt so often that it would bring few, if any, advantages in efficiency to the filter.